Problem

When a remote peer unpublishes an audio track, a subscriber consuming the resulting AudioStream via for await (const frame of stream) hangs indefinitely - the loop never receives an end-of-stream and the process can't exit. Calling iterator.return() or stream.cancel() to force termination doesn't help either - the in flight promise returned by reader.read() never resolves.

Root cause

The native FFI side only emits eos on the audio stream when one of: (a) the stream's own FFI handle is disposed, (b) the track's FFI handle is disposed, or (c) the underlying libwebrtc receiver gracefully ends. None of these reliably fire on a remote unsubscribe - the SDK keeps the track handle alive (the consumer may still want to read track.sid etc.), and (according to a LLM) the libwebrtc receiver typically keeps the stream "open" with silence rather than ending it.

On the SDK side, AudioStreamSource.cancel() previously disposed the FFI handle but never closed the ReadableStream controller. The native eos (if it ever arrived) would have triggered the close - but since the event listener was removed at the top of cancel(), even a late eos was silently dropped. So any pending reader.read() had nothing to resolve it.

Fix

Two changes in packages/livekit-rtc/src/:

1. audio_stream.ts: collapse the three cleanup paths ('eos' event, consumer cancel(), and a new closeFromTrack() entry point) into one teardown() method that closes the ReadableStreamDefaultController first. Closing the controller synchronously resolves any pending reader.read() with {done: true}, so for await / iterator.return() unblock without relying on the native eos arriving.

2. track.ts: when a Track is detached from its Room (the natural signal that no more frames will arrive on its streams), call closeFromTrack() on each registered AudioStream. This gives consumers a clean end-of-stream even when the native layer doesn't emit one.

TODO

• Add new tests specifically for this case
• More through manual testing